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Abstract 


A  well-known  problem  within  the  serviee-oriented  arehiteeture  (SOA)  eommunity  is  the  need  to 
establish  effeetive  SOA  govemanee  proeedures  to  enable  an  organization-wide  SOA  initiative.  A 
number  of  organizations  and  vendors  address  this  problem  through  SOA  govemanee  frameworks 
that  provide  models,  proeedures,  and  tools  for  SOA  govemanee.  Many  of  these  SOA  frameworks 
are  general  purpose  beeause  they  are  intended  to  be  useful  for  a  diverse  eustomer  base.  However, 
while  designed  for  a  wide  eustomer  base,  vendor  SOA  frameworks  tend  to  be  narrowly  foeused  to 
work  with  the  speeifie  tools  of  the  vendor.  A  eritieal  problem  for  an  organization  when  imple¬ 
menting  SOA  govemanee  is  to  eustomize  vendors’  offerings  to  its  speeifie  teehnologieal  and 
management  eontext.  In  this  teehnieal  note,  a  lightweight  and  extensible  teehnique  is  proposed, 
one  that  employs  seenarios  to  tailor  existing  SOA  govemanee  frameworks  to  the  speeifie  needs  of 
an  organization. 
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1  Introduction 


Service-oriented  architecture  (SOA)  is  a  way  of  designing,  developing,  deploying,  and  managing 
systems  characterized  by  coarse-grained  services  that  represent  reusable  business  functionality. 
Service  consumers  compose  applications  or  systems  using  the  functionality  provided  by  these 
services  through  standard  interfaces.  At  a  high  level,  SOA  is  a  way  to  design,  develop,  deploy, 
and  manage  systems  in  which 

•  Services  provide  reusable  business  functionality. 

•  Service  consumers  are  built  using  functionality  from  available  services.  Examples  of  ser¬ 
vices  consumers  are  end-user  applications,  portals,  internal  systems,  external  systems,  and 
composite  services. 

•  Service  interface  definitions  are  first-class  artifacts. 

•  An  SOA  infrastructure  enables  discovery,  composition,  and  invocation  of  services. 

•  Protocols  are  predominantly,  but  not  exclusively,  message-based  document  exchanges. 

From  a  more  technical  point  of  view,  SOA  is  an  architectural  style  or  design  paradigm — it  is  nei¬ 
ther  a  system  architecture  nor  a  complete  system.  As  an  architectural  style,  it  is  characterized  by  a 
set  of  components  and  connectors,  situations  when  the  style  is  applicable,  and  benefits  associated 
with  implementing  the  style. 

If  implemented  correctly,  SOA  adoption  can  provide  business  agility,  reuse  of  business  function¬ 
ality,  and  leverage  of  legacy  systems  for  an  organization.  Many  organizations  recognize  these 
potential  benefits  and  are  adopting  SOA — some  more  successfully  than  others.  SOA  has  indeed 
“crossed  the  chasm,” '  according  to  a  recent  Software  AG  user  survey  in  which  90%  of  the  re¬ 
spondents  claim  to  have  made  some  commitment  to  SOA  adoption  [17]. 

But  there  are  concerns,  chief  of  which  appears  to  be  SOA  governance.  The  Software  AG  user  sur¬ 
vey  also  reveals  that  “an  overwhelming  percentage  of  respondents  (over  90%)  view  governance  as 
significant  with  54%  calling  it  critical”  [17].  Further,  Gartner  has  identified  the  lack  of  govern¬ 
ance  as  the  most  common  reason  for  failure  of  SOA  projects  [1],  and  an  InfoWorld  2007  SOA 
Trend  Survey  labels  the  lack  of  governance  is  the  main  inhibitor  for  SOA  adoption  (50%)  [2].  An 
ebizQ  survey  on  SOA  governance  funded  by  Oracle  covering  1 1 8  companies,  reveals  that  most 
organizations  believe  that  SOA  governance  is  a  critical  part  of  their  SOA  strategy,  with  49%  be¬ 
lieving  that  without  governance  their  SOA  plans  will  fail  [18]. 

There  are  several  definitions  of  SOA  governance.  For  example,  IBM  defines  SOA  governance  as 
the  process  of  establishing  the  chain  of  responsibilities  and  communications,  policies,  measure¬ 
ments,  and  control  mechanisms  that  allow  people  to  carry  out  their  responsibilities  in  SOA  pro¬ 
jects  [3].  eBizQ  states  that  SOA  governance  provides  organizations  with  the  processes,  policies, 
and  solutions/technologies  that  can  help  to  manage  increasingly  complex  SOA  deployments  in  an 
effective  and  efficient  manner  [18]. 

^  This  term  was  coined  by  Geoffrey  Moore  in  his  book  Crossing  the  Chasm:  Marketing  and  Seiiing  High-Tech 
Products  to  Mainstream  Customers  to  refer  to  the  chasm  that  exists  between  visionaries  (early  adopters)  and 
pragmatists  (early  majority),  from  a  technology  adoption  perspective. 
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In  general,  SOA  govemanee  provides  a  set  of  polieies,  rules,  and  enforeement  meehanisms  for 
developing,  using,  and  evolving  serviee-oriented  systems,  and  for  analysis  of  the  business  value 
of  those  systems.  SOA  govemanee  ineludes  polieies,  proeedures,  roles,  and  responsibilities  for 
design-time  govemanee  and  mntime  govemanee.  Design-time  govemanee  ineludes  elements  sueh 
as  mles  for  strategie  identifieation,  development,  and  deployment  of  serviees;  reuse;  and  legaey 
system  migration.  It  also  enforees  eonsisteney  in  use  of  standards,  SOA  infrastmeture,  and  proe- 
esses.  Runtime  govemanee  develops  and  enforees  mles  to  ensure  that  serviees  are  exeeuted  only 
in  ways  that  are  legal  and  that  important  mntime  data  is  logged.  From  a  life-eyele  point  of  view, 
design-time  govemanee  applies  to  early  aetivities  sueh  as  planning,  arehiteeture,  design,  and  de¬ 
velopment.  Runtime  govemanee  applies  to  deployment  and  management  of  serviee-oriented  sys¬ 
tems. 

Often,  organizations  begin  their  exposure  to  SOA  with  small  pilot  projeets  that  provide  the  envi¬ 
ronment  to  experienee  and  learn  about  various  aspeets  of  serviee  orientation.  However,  these  pilot 
projeets  are  often  pragmatieally  limited  to  experimentation  with  teehnieal  feasibility  and  do  not 
address  SOA  govemanee.  Even  when  SOA  govemanee  is  addressed,  the  results  are  unlikely  to 
seale  to  organization-wide  SOA  efforts,  leaving  many  eritieal  SOA  govemanee  questions  unan¬ 
swered,  sueh  as: 

•  What  serviees  should  be  implemented? 

•  Does  a  proposed  serviee  represent  a  new,  reusable  eapability? 

•  How  are  serviee  ehanges  and  upgrades  deeided  and  eommunieated? 

•  What  are  expeetations  for  serviee  verifieation  and  validation? 

•  Who  pays  for  maintenanee  and  development  of  serviees? 

•  Who  owns  a  serviee  and  the  data  it  uses? 

There  are  multiple  SOA  govemanee  frameworks  that  provide  basie  govemanee  eoneepts  to  sup¬ 
port  SOA  adopters.  Some  of  these  are  offered  by 

•  IT  market  leaders  sueh  as  IBM  and  Oraele  [4],  [5] 

•  niehe  SOA  vendors  and  eonsultants  sueh  as  SOA  Software,  Software  AG  and  AgilePath  [6], 

[7],  [8] 

•  independent  eonsulting  eompanies  sueh  as  CBDi  [9] 

•  industry  organizations,  even  if  they  are  not  SOA  speeifie,  sueh  as  the  Information  Teehnol- 
ogy  Infrastmeture  Library  (ITIL)  [  1 0] 

These  frameworks  ean  be  very  useful;  they  define  speeifie  voeabulary  and  identify  the  basie  eapa- 
bilities  of  SOA  govemanee.  Some  even  suggest  arehiteetures  and  identify  best  praetiees,  partieu- 
larly  for  use  of  vendor-speeifie  tools.  They  were  developed  based  on  experienees  of  aetual  organi¬ 
zations,  and  as  sueh  represent  abstraeted  and  generalized  eritieal  features  of  SOA  govemanee.  The 
frequent  failures  of  SOA  govemanee  are  not  due  to  these  frameworks,  but  to  the  inability  of  or¬ 
ganizations  to  relate  and  adapt  them  to  their  speeifie  eontexts.  While  the  frameworks  suggest  in 
general  what  is  involved  in  SOA  govemanee,  they  do  not  tell  organizations  speeifieally  what  to 
do  and  how  to  do  it. 

This  report  proposes  a  seenario-based  teehnique  for  tailoring  existing  SOA  govemanee  frame¬ 
works  in  order  to  establish  a  eustomized  SOA  govemanee  strategy  that  addresses  the  needs  of  a 
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specific  organization  adopting  SOA.  Although  the  technique  could  be  applied  in  a  multi- 
organizational  context,  and  some  elements  of  the  established  strategy  could  involve  relationships 
with  other  organizations,  the  focus  of  this  report  is  the  implementation  within  a  single  organiza¬ 
tion.  Section  2  presents  concepts  related  to  SOA  governance  and  analyzes  several  existing  SOA 
governance  frameworks  to  identify  common  elements  in  these  frameworks.  Section  3  presents  a 
scenario-based  technique  for  identifying  organization-specific  SOA  governance  needs  and  for 
tailoring  SOA  governance  frameworks  to  address  these  needs.  Section  4  summarizes  and  con¬ 
cludes  the  report. 
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2  Existing  Governance  Frameworks 


Existing  SOA  governance  frameworks  are  diverse,  employ  unique  vocabularies,  and  possess  dif¬ 
ferent  strengths  and  limitations.  However,  there  are  many  common  elements  across  these  frame¬ 
works  that  are  often  obscured  by  their  unique  vocabularies  and  marketing  jargon.  This  section 
presents  an  abstract  architecture  of  existing  SOA  governance  frameworks  that  removes  vendor- 
and  implementation-specific  details  and  summarizes  the  core  concepts  using  a  simple,  generic 
vocabulary.  The  SOA  governance  frameworks  listed  in  Section  1  were  considered  for  this  analy¬ 
sis  because  of  their  widespread  popularity  in  the  SOA  community. 


Figure  1:  Entity-Relationship  Diagram  of  SOA  Governance  Framework  Elements 

Figure  1  shows  and  abstraction  of  the  following  common  elements  in  these  SOA  governance 
frameworks,  expressed  as  a  simple  entity-relationship  diagram. 

•  SOA  Governance 

•  IT  Governance 

•  Corporate  Governance 

•  Best  Practices 
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•  Processes 

•  Software  Tools 

•  SOA  Polieies 

•  Complianee 

•  SOA  Center  of  Exeellenee  (CoE) 

•  Referenee  Arehiteeture 

•  Maturity  Models 

Seetions  2.1  through  2.5  diseuss  the  entities  presented  in  Figure  1,  as  well  as  some  important  rela¬ 
tionships  among  these  entities. 

2.1  SOA  Governance  is  Part  of  Corporate  and  IT  Governance 

All  of  the  govemanee  frameworks  studied  for  this  report  assume  that  SOA  govemanee  is  part  of  a 
larger  eorporate  govemanee  or  IT  govemanee  framework.  For  example,  not  allowing  the  installa¬ 
tion  of  eertain  software  produets  on  offiee  maehines  due  to  seeurity  eoneems  is  an  example  of  IT 
govemanee  that  is  not  related  to  SOA  govemanee.  This  implies  that  any  implementation  of  a  new 
SOA  govemanee  framework  must  be  done  in  the  eontext  of  eorporate  and  IT  govemanee  models 
and  praetiees  and  must  fit  the  organization’s  unique  eulture.  Organizations  adopting  an  SOA  gov¬ 
emanee  framework  should  be  elear  about  how  it  supports  broader  business  and  IT  goals.  Some 
frameworks  strongly  suggest  ereating  an  SOA  CoE  to  oversee  the  strategy  and  implementation  of 
SOA  govemanee  meehanisms  organization-wide.  The  seenario-based  teehnique  proposed  in  this 
report  eould  be  orehestrated  by  an  SOA  CoE. 

2.2  SOA  Governance  is  Incremental  and  Based  on  Maturity  Models 

Aeross  the  frameworks  we  eonsidered,  there  is  agreement  that  an  organization  should  implement 
SOA  govemanee  inerementally.  An  ineremental  approaeh  involves  (1)  analyzing  the  organiza¬ 
tion’s  existing  IT  and  SOA  govemanee  stmetures  (e.g.,  polieies,  proeesses,  tools,  organizational 
units)  and  the  future  govemanee  required  for  SOA  and  (2)  determining  a  step-wise  approaeh  for 
implementing  SOA  govemanee  or  improving  and  enhaneing  if  it  already  exists.  An  ineremental 
approaeh  will  allow  an  organization  to  adopt  best  praetiees  gradually — and  learn  from  early  mis¬ 
takes  to  improve  subsequent  praetiees.  In  addition,  an  organization  ean  put  in  plaee  SOA  govem¬ 
anee  strategies  that  support  early  phases  of  migration  to  SOA.  For  example,  an  organization  ean 
determine  that  the  first  step  in  migrating  will  involve  implementing  serviees  that  are  exaetly  ana¬ 
logous  to  existing,  non-SOA  eapabilities.  SOA  govemanee  praetiees  ean  verify  the  analogous  na¬ 
ture  of  the  new  serviees  and  support  their  deployment.  Applieations  ean  then  eode  ealls  to  these 
serviees  in  plaee  of  existing  ealls  (or  whatever  meehanism  was  used).  At  this  stage,  it  may  be  ap¬ 
propriate  to  put  in  plaee  praetiees  to  ensure  that  serviees  are  invoked  and  used  appropriately  by 
applieations. 

A  key  feature  of  SOA  govemanee  frameworks  is  the  ineorporation  of  a  maturity  model  that  eva¬ 
luates  the  sophistieation  of  the  polieies  and  praetiees  in  plaee  within  an  organization.  The  ration¬ 
ale  for  maturity  models  is  that  as  organizations  beeome  more  mature  with  respeet  to  SOA  adop¬ 
tion,  govemanee  aligned  with  the  inereased  maturity  is  warranted.  Some  form  of  maturity  model 
is  present  in  all  the  eonsidered  frameworks,  although  the  aetual  models  are  quite  different.  IBM 
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has  perhaps  the  most  eomprehensive  model  [1 1].  It  is  based  on  the  type  and  maturity  of  integra¬ 
tion  (data  integration,  applieation  integration,  funetional  integration,  proeess  integration,  supply- 
ehain  integration,  virtual  infrastrueture,  and  eeo-system  integration)  inside  an  organization.  The 
CBDI  maturity  model  is  foeused  on  the  maturity  of  polieies,  proeesses,  organization,  and  infra¬ 
strueture  [12], 

2.3  Policies,  Processes,  and  Best  Practices 

An  SOA  poliey,  as  shown  in  Figure  1,  is  a  direetive  or  strategy  that  is  defined  independently  of 
how  it  will  be  earried  out.  For  example,  a  poliey  might  require  that  all  serviees  undergo  eertifiea- 
tion  before  they  ean  be  used.  Polieies  are  implemented  through  proeesses  and  ideally  should  be 
influeneed  by  best  praetiees. 

Polieies  are  important  elements  of  all  SOA  govemanee  frameworks,  but  polieies  differ  widely  in 
terms  of  their  importanee,  seope,  speeifieity,  and  potential  implementations.  Some  polieies  sueh 
as  those  related  to  serviee  usage  and  quality  of  serviee  monitoring  ean  be  formally  speeified  and 
enforeed  automatieally.  Others  require  the  eommitment  and  diseipline  of  people  to  adhere  to  spe- 
eifie  proeesses  that  support  the  poliey  in  order  to  aehieve  desired  outeomes  and  eomplianee. 

Not  all  polieies  are  equally  eonstraining — some  are  merely  guidelines.  For  example,  guidelines 
are  often  ereated  for  identifying  preferred  granularity  of  serviees.  However,  a  partieular  serviee 
may  be  an  exeeption  to  the  guideline  due  to  speeifie  quality  requirements  (e.g.,  performanee). 
Other  polieies  are  more  stringent  and  ean  result  in  eritieal  eonsequenees  when  violated.  For  ex¬ 
ample,  failure  to  eomply  with  a  poliey  requiring  registration  of  new  serviees  results  in  duplieation 
of  serviees  aeross  the  organization.  This  violation  is  eounterproduetive  to  the  goal  of  organiza¬ 
tion-wide  reuse. 

2.4  Policy  Compliance  and  Enforcement  Mechanisms 

All  of  the  frameworks  we  eonsidered  inelude  an  emphasis  on  eomplianee  and  enforeement.  In  the 
ease  of  vendor-ereated  SOA  frameworks,  eomplianee  and  enforeement  strategies  are  eonsistent 
with  and  supported  by  the  SOA  produets  they  market.  For  example,  vendors  with  strong  reposi¬ 
tory/registry  produets  advoeate  runtime  monitoring  and  enforeement  of  serviee  usage  that  ean  be 
aeeomplished  by  their  produets,  while  those  vendors  with  strong  modeling  and  design  support 
prefer  to  emphasize  govemanee  eontrolling  the  design  of  serviees. 

There  are  numerous  eommereial  software  tools  that  implement  aspeets  of  SOA  govemanee  by 
supporting  speeifie  polieies  and  monitoring  eomplianee.  While  tools  supporting  eomplianee  and 
monitoring  for  the  majority  of  the  serviee  life  eyele  are  available,  no  single  vendor  provides  a  full 
suite  of  tools  or  an  integrated  solution.  One  of  the  biggest  ehallenges  is  ereating  a  “best-of-breed” 
solution  by  integrating  various  produets  [13].  Unfortunately,  there  are  no  SOA-speeifie  govern- 
anee  standards  [14].  There  are  also  no  standards  that  allow  govemanee  tools  to  be  easily  tied  to¬ 
gether  into  an  integrated  solution.  Thus,  building  a  best-of-breed  solution  for  SOA  govemanee 
and  eomplianee  will  remain  a  diffieult  task,  whieh  might  be  eased  if  vendors  adopted  standards. 
On  the  other  hand,  standardizing  all  aspeets  of  SOA  govemanee  may  be  unrealistie  and  may  not 
yield  all  the  benefits  assoeiated  with  standardization.  First,  given  that  SOA  govemanee  is  part  of 
IT  govemanee  and  eaeh  organization  has  speeifie  SOA  needs,  standardizing  all  aspeets  of  SOA 
govemanee  will  require  all  organizations  to  follow  the  same  IT  govemanee  approaeh,  whieh  is 
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unlikely  and  unrealistic.  Secondly,  most  aspects  of  SOA  governance  are  limited  to  a  single  or¬ 
ganization,  which  means  that  standardization  in  the  context  of  SOA  governance  would  be  more 
beneficial  where  inter-organization  interoperation  is  important,  which  is  not  always  the  case. 

2.5  SOA  Center  of  Excellence 

Many  frameworks  strongly  suggest  the  creation  of  SOA  CoE  that  not  only  promotes  adoption  of 
SOA  best  practices  organization-wide  but  can  also 

•  evaluate  and  recommend  SOA  governance  tools  and  products  best  suited  for  the  organization 

•  keep  track  of  the  latest  technologies  and  vendor  products 

•  help  various  units  inside  the  organization  adopt  existing  governance  policies  and  create  new 
ones,  if  required. 

•  monitor  the  compliance  to  SOA  governance  policies  across  the  organization,  as  well  as  pro¬ 
vide  the  business  with  a  realistic  analysis  of  the  maturity  of  the  service-oriented  initiatives. 

Although  creating  a  CoE  is  widely  recommended,  it  is  not  necessary  for  establishing  SOA  gov¬ 
ernance. 
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3  Developing  SOA  Governance  Using  Scenarios 


Many  organizations  considering  SOA  adoption  are  at  least  somewhat  aware  of  the  governance 
frameworks  of  various  vendors  and  industry  groups.  However,  the  SOA  governance  needs  of 
these  organizations  vary  across  a  wide  spectrum.  On  one  end  are  organizations  where  extreme 
agility  in  producing  new  applications  and  services  is  key  (either  direetly  by  the  organization  or  by 
other  interested  parties).  On  the  other  end  are  SOA  implementations  in  the  U.S.  Department  of 
Defense  (DoD)  that  involve  military  eommand  and  eontrol  and  real-time  surveillanee  where  there 
is  a  high  need  for  eontrol. 

Clearly,  the  same  SOA  govemanee  solution  or  framework  is  not  appropriate  for  everyone.  Some 
differentiators  are  eultural — teehnieal  sophistieation,  applieation  domain,  proeess  diseiplines, 
business/mission  goals,  and  market  profile.  In  most  eases,  it  is  neither  desirable  nor  possible  for 
organizations  to  direetly  adopt  a  solution  from  a  single  vendor.  In  some  eases,  organizations  may 
find  the  vendor  govemanee  frameworks  overwhelming.  Also,  organizations  may  find  that  their 
unique  SOA  govemanee  needs  and  eharaeteristies  of  existing  inffastmeture,  applieations,  and  IT 
govemanee  approaehes  impose  eonstraints  that  preelude  single  vendor  strategies.  These  organiza¬ 
tions  may  eonsider  building  their  own  SOA  govemanee  implementation. 

Thus,  while  organizations  may  be  aware  of  the  available  govemanee  frameworks,  they  also  might 
be  eonfused  about  what  SOA  govemanee  ean  do  for  them,  what  SOA  govemanee  aetually  entails 
for  them,  whieh  speeifie  govemanee  eapabilities  they  should  implement,  and  what  strategies  for 
adopting  those  eapabilities  they  should  employ.  They  probably  understand  the  need  for  SOA  gov¬ 
emanee,  but  they  do  not  understand  how  to  implement  SOA  govemanee  within  their  speeifie  eon- 
text. 

We  believe  there  is  a  need  for  an  impartial  teehnique  that  distills  and  simplifies  the  key  elements 
of  the  existing  eommereial  models,  and  allows  organizations  to  quiekly  understand  what  they 
need  to  do  to  build  appropriate  SOA  govemanee.  The  approaeh  that  we  propose  supports  organi¬ 
zations  in  understanding  their  SOA  govemanee  needs  and  the  eontext  in  whieh  they  need  to  im¬ 
plement  SOA  govemanee.  This  approaeh  foeuses  only  on  the  teehnieal  aspeets  of  SOA  govem¬ 
anee.  For  example,  human  resouree  alloeation  or  funding  issues  related  to  an  SOA  projeet  are 
outside  the  seope  of  this  approaeh. 

In  addition,  many  organizations  play  multiple  roles  or  address  multiple  perspeetives  in  their  SOA 
implementations.  They  build  serviees  (serviee  provider),  develop  applieations  that  eonsume  ser- 
viees  (serviee  eonsumer),  and  also  build  their  SOA  inffastmeture  (inffastmeture  provider),  often 
beeause  of  the  unique  demands  of  the  SOA  environment  they  are  establishing.  Other  organiza¬ 
tions  are  playing  only  one  or  two  of  these  roles,  as  in  the  example  of  organizations  that  are  devel¬ 
oping  or  using  third-party  serviees.  Effeetive  SOA  govemanee  for  these  organizations  has  to  eon¬ 
sider  eaeh  of  the  relevant  perspeetives  operative  in  a  given  eontext.  The  seenario-based  teehnique 
proposed  here  takes  into  aeeount  these  perspeetives  without  going  into  speeifie  roles. ^  Eaeh  see- 


The  SOA  governance  frameworks  analyzed  go  into  very  specific  details  about  roles  and  responsibilities  (e.g., 
SOA  Architect,  SOA  Designer)  but  do  not  consider  the  distinction  between  the  perspectives  of  service  con¬ 
sumer,  service  provider,  and  infrastructure  provider  that  we  believe  are  important. 
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nario  provides  the  eontext  and  requirements  for  a  speeifie  situation  related  to  teehnieal  aspeets  in 
an  SOA  projeet.  The  elements  of  a  seenario  are  defined  in  Seetion  3.5. 

Charaeteristies  of  the  teehnique  inelude 

•  vendor-neutral  and  applieable  regardless  of  whieh  vendor-provided  or  eustom  SOA  govem- 
anee  framework  is  adopted 

•  seenario-based  to  eapture  organization-speeifie  governanee  eoneems 

•  risk-aware  to  support  organizations  in  the  analysis  and  remediation  of  potential  problems  in 
governanee 

The  teehnique  is  not  intended  to  replaee  existing  eommereial  offerings,  but  to  provide  a  starting 
point  to  help  organizations  understand  their  speeifie  SOA  governanee  needs  and  navigate  the 
available  offerings.  Thus,  the  teehnique  ean  be  applied  in  eonjunetion  with  the  governanee 
frameworks  we  have  eonsidered  or  any  other  existing  frameworks. 

3.1  Overview  of  the  Technique 

The  teehnique  employs  six  aetivities  to  understand  the  organization’s  eontext  and  to  ereate  seenar- 
ios  relating  to  an  existing  SOA  governanee  framework.  These  aetivities  inelude 

1 .  Establish  eontext — SOA  governanee  drivers,  framework,  and  seope. 

2.  Develop  elassifieation  sehemes. 

3.  Create  affinity  groups  by  SOA  governanee  needs. 

4.  Create  and  refine  seenarios  of  SOA  governanee  needs. 

5.  Consolidate  seenarios. 

6.  Customize  polieies  to  fit  SOA  governanee  framework. 

A  visual  representation  of  the  teehnique  is  presented  in  Figure  2,  in  whieh  the  direetion  of  the  ar¬ 
rows  illustrates  the  flow  of  aetivities.  This  figure  shows  that  the  first  three  aetivities  ean  be  per¬ 
formed  eoneurrently.  However,  for  a  single  iteration  they  should  be  eompleted  before  the  individ¬ 
ual  groups  ean  start  developing  seenarios  (even  if  there  is  a  need  to  revisit  these  aetivities  at  some 
point  in  the  proeess).  The  remaining  aetivities  are  sequential.  The  loop  shown  in  Figure  2  from 
Aetivity  6  baek  to  Aetivity  1  refleets  an  ineremental  approaeh  to  SOA  governanee  that  requires 
eontinuous  revision  of  the  eontext,  the  groupings  of  SOA  governanee  elements,  and  the  grouping 
of  organizational  units. 
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Figure  2:  Visual  Representation  of  a  Technique  for  SOA  Governance  Development 

Activities  1  and  2  in  Figure  2  (Establish  Context  and  Develop  Classification  Schemes)  are  organi¬ 
zation-wide  actions  that  should  be  performed  by  a  central  authority  (such  as  the  SOA  CoE)  to  fos¬ 
ter  general  agreement.  Create  Affinity  Groups,  Activity  3,  requires  interaction  between  the  central 
authority  and  the  various  lines  of  business  involved  (or  planning  to  be  involved)  in  SOA  efforts. 
Activity  4  (Create  Scenarios)  is  repeated  for  each  of  the  organizational  units  identified  in  Activity 
3.  The  final  two  activities,  Consolidate  Scenarios  and  Customize  Policies,  build  on  the  results  of 
previous  ones.  Activity  5  consolidates  ah  the  scenarios  identified  in  Activity  4  by  each  group. 
Activity  6  relates  the  work  of  the  previous  activities  to  the  organization’s  chosen  SOA  governance 
framework.  Each  activity  in  the  technique  is  described  in  a  subsequent  section. 
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3.2  Activity  1:  Establish  Context 


The  goal  of  establishing  eontext  is  to  eolleet  and  reeord  information  that  will  guide  the  seenario 
and  poliey  generation  aetivities.  One  part  of  establishing  eontext  is  determining  the  business  driv¬ 
ers  or  justifieation  for  SOA  govemanee.  For  example,  the  organization  may  be  driven  to  ensure 
that  all  users  of  a  business  serviee  aeeess  the  same  eapability — that  there  is  eonsistent  and  wide¬ 
spread  use  of  the  same  serviee  within  the  organization.  Or,  the  organization  may  be  driven  to  en¬ 
sure  that  no  “rogue”  versions  of  serviees  ean  be  used  and  that  all  serviees  are  eompletely  vetted 
for  seeurity,  reliability,  and  other  qualities  (i.e.,  eertified)  prior  to  deployment.  If  these  drivers 
have  not  previously  been  made  explieit,  they  must  be  made  so  at  this  point  to  inform  all  partiei- 
pants  in  the  seenario  generation  proeess  about  the  expeetations  of  the  organization. 

Another  part  of  establishing  eontext  is  identifying  the  seope  of  the  SOA  govemanee  effort.  If  it  is 
impossible  to  develop  a  eonsistent  set  of  drivers  for  all  partieipants  (i.e.,  if  various  partieipants  are 
expeeted  to  respond  to  different  goals),  the  eontext  of  the  seenario-based  aetivity  should  be  sealed 
to  assure  that  all  partieipants  are  responding  to  eonsistent  drivers.  One  result  of  sealing  the  eontext 
may  be  that  multiple  implementations  of  the  seenario-based  teehnique  are  needed  for  groups  with¬ 
in  the  organization  that  must  address  disjointed  SOA  govemanee  drivers. 

The  final  part  of  establishing  eontext  is  seleeting  an  SOA  govemanee  framework  that  addresses 
the  identified  drivers.  This  SOA  govemanee  framework  ean  be  an  existing  framework  from  a 
eommereial  vendor,  one  based  on  a  standard  or  a  widely  reeommended  approaeh  sueh  as  ITIL, 
one  eustom-built  for  the  organization,  or  a  hybrid  of  all  of  the  preeeding.  For  organizations  that 
have  IT  govemanee  in  plaee,  the  most  logieal  step  is  to  seleet  an  SOA  govemanee  framework  that 
is  eonsistent  with  existing  IT  govemanee. 

3.3  Activity  2:  Develop  Classification  Schemes 

Classifieation  sehemes  are  used  to  eategorize  seenarios  and  the  polieies  designed  to  address  prob¬ 
lems  they  raise.  The  sehemes  ean  often  be  simply  based  on  the  seleeted  SOA  govemanee  frame¬ 
work.  Common  elassifieation  sehemes  group  seenarios  aeeording  to  goals  (e.g.,  serviee  eertifiea- 
tion),  life-eyele  phase  (e.g.,  serviee  design  time),  foeus  of  aetivity  (e.g.,  fmaneial,  teehnology),  or 
usage  (e.g.,  externally  visible  serviees,  internally  visible  serviees).  For  example,  CBDi  provides  a 
model  of  the  serviee  life-eyele  phases  (feasibility,  approval,  design,  build/integrate,  and  launeh) 
that  ean  serve  as  a  elassifieation  seheme  [9].  Oraele  provides  a  framework  for  polieies  related  to 
people,  fmaneial,  portfolio,  operation,  arehiteeture,  information,  teehnology,  and  projeet  exeeu- 
tion  as  shown  in  Figure  3  [5].  This  framework  ean  be  the  impetus  for  an  alternate  elassifieation 
seheme. 

elassifieation  sehemes  also  provide  a  shorthand  for  diseussing  groups  of  govemanee  seenarios 
and  polieies  and  support  effieient  eommunieation  among  partieipants.  In  addition,  to  ensure  broad 
eoverage  of  govemanee  eoneems  in  the  seenarios  and  simplify  the  eonsolidation  of  the  efforts  of 
multiple  partieipants,  elassifieation  sehemes  should  be  developed  as  input  to  seenario  generation.^ 


It  may  be  the  case,  especially  in  organizations  new  to  governance,  that  classification  schemes  identified  as 
scenarios  are  generated  in  the  next  step.  If  this  is  the  case,  the  classification  schemes  need  to  be  updated  for 
all  other  groups  so  that  everyone  uses  the  same  classification — an  aid  also  for  the  consolidation  step. 
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It  is  often  useful  to  employ  multiple  elassifieation  sehemes.  For  example,  an  organization  may 
find  value  in  applying  both  a  life  eyele  phase  seheme  like  that  of  CBDi  to  identify  the  major  stag¬ 
es  a  serviee  will  go  through,  as  well  as  an  aetivity-foeused  seheme  like  that  of  Oraele  to  ensure 
that  all  aspeets  of  govemanee  are  eovered  in  eaeh  life-eyele  phase. 
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Figure  3:  SOA  Governance  Elements  in  Oracle’s  SOA  Governance  Framework 


3.4  Activity  3:  Create  Affinity  Groups  by  SOA  Governance  Needs 

The  first  two  activities  are  best  accomplished  by  employing  a  top-down  approach  under  control  of 
a  central  authority  such  as  a  CoE.  However,  central  authority  insight  is  limited  by  the  differing 
SOA  governance  needs  within  the  organization.  Indeed,  it  is  difficult  (and  some  would  argue  im¬ 
possible)  for  a  central  authority  to  identify  the  full  range  and  scope  of  governance  issues  within 
the  organization  or  to  understand  the  ramifications  of  the  selected  SOA  governance  frameworks 
on  all  parts  of  the  organization. 

These  different  needs  are  driven  by  varying  views  of  the  governance  problem  and  different  ways 
that  various  groups  must  respond  to  solve  problems.  Groups  with  similar  and  related  needs  (affin¬ 
ity  groups)  are  created  and  tasked  with  creating  scenarios  to  capture  these  different  viewpoints. 
One  common  and  logical  approach,  for  example,  is  to  group  according  to  lines  of  business. 

We  recommend  two  guidelines  for  affinity  group  membership.  First,  the  grouping  process  should 
lead  to  group  sizes  that  are  manageable  and  allow  the  productive  generation  of  scenarios."^  Sec¬ 
ond,  each  group  should  incorporate  representatives  of  the  three  perspectives  of  service  provider, 
infrastructure  provider,  and  service  consumer,  if  they  all  exist  in  the  given  organization  whose 
governance  scope  is  under  consideration. 

3.5  Activity  4:  Create  and  Refine  Scenarios  of  SOA  Governance  Needs 

Scenarios  are  generated  independently  by  each  of  the  affinity  groups  established  in  Activity  3. 
Generating  appropriate  scenarios  that  provide  broad  coverage  of  SOA  governance  will  likely  re¬ 
quire  multiple  brainstorming  sessions.  Each  session  is  typically  held  as  a  workshop  to  encourage 
insightful  thinking  about  the  real  problems  that  the  group  will  face  in  SOA  governance.  Similar 


Literature  on  brainstorming  and  team  exercises  claims  that  ideal  group  size  is  3-5  people,  with  a  maximum  of 
12-15  people,  plus  a  facilitator. 
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scenario-based  approaches  have  been  successfully  applied  in  many  engineering  contexts,  includ¬ 
ing  requirements  analysis  and  architecture  tradeoff  analysis  [15],  [16]. 

The  initial  round  of  brainstorming  is  intended  to  elicit  broad  coverage  of  governance  problems,  a 
goal  supported  by  requiring  groups  to  eonsider  a  set  of  seenarios  that  address  as  many  eategories 
within  the  elassifieation  seheme  as  possible.  To  aeeomplish  this,  the  faeilitator  goes  through  eaeh 
eategory  in  the  elassifieation  seheme  and  asks  the  group  to  think  about  situations  that  eould  lead 
to  problems  whieh  eould  be  alleviated  if  there  were  some  kind  of  poliey  or  eontrol  in  plaee.  For 
example,  using  Oraele’s  elassifieation  seheme,  a  eoneem  under  Operations  eould  be  aeeess  to 
unauthorized  data,  a  eoneem  under  Technology  eould  be  ineonsistent  use  of  a  partieular  teehnol- 
ogy  by  serviee  developers,  and  a  eoneem  under  People  eould  be  the  definition  of  the  role  respon¬ 
sible  for  registry  maintenanee. 

Following  this  initial  round,  the  groups  may  need  to  reeonsider  the  list  of  seenarios  by  validating 
them  against  the  drivers  and  seope  of  SOA  govemanee.  In  an  extreme  ease,  it  might  be  neeessary 
to  revisit  the  first  aetivity  in  the  proeess  beeause  the  seenario(s)  may  not  be  aehievable  in  the  eon- 
text.  At  this  point,  the  group  is  asked  to  remove,  merge,  add,  or  reword  seenarios,  if  neeessary. 
Eaeh  final  seenario  is  then  doeumented  using  the  template  provided  in  Table  1. 


Table  1:  SOA  Governance  Scenario  Template 


Scenario  Element 

Description 

Concern 

Very  informal  description  of  a  concern  with  respect  to  SOA  adoption 

Scenario  Description 

Concise  description  of  a  situation,  the  context  in  which  the  situation  occurs, 
and  the  participants  in  the  situation  that  would  address  the  above  concern 

Governance  Drivers 

The  specific  SOA  governance  drivers  (defined  in  Section  3.2)  that  must  be 
addressed  in  any  policies  that  are  created  to  address  the  scenario. 

Scenario  Categories 

Each  service  should  be  related  to  at  least  one  category  that  is  part  of  the 
classification  scheme  defined  previously.  For  example,  if  the  classification 
scheme  is  based  on  service  life-cycle  phases,  then  a  scenario  involving 
avoiding  redundancy  in  services  may  be  categorized  as  planning  phase 
governance.  A  single  scenario  may  be  categorized  into  more  than  one  cate¬ 
gory  (e.g.,  design-time  and  runtime)  or  there  may  be  multiple  classification 
schemes  (e.g.,  service  life  cycle  and  business  line). 

Perspectives 

We  identify  three  primary  perspectives  involved  in  SOA  governance:  service 
provider,  service  consumer,  and  infrastructure  provider.  Separating  these 
three  perspectives  offers  a  valuable  abstraction  for  understanding  govern¬ 
ance  issues.  Each  perspective  will  likely  map  to  multiple  roles  within  the 
organization. 

Policies 

Policies  are  a  starting  point  for  implementing  governance.  A  scenario  may 
map  to  multiple  policies.  For  example,  a  scenario  involving  release  of  new 
versions  of  a  service  may  map  to  policies  for  service  providers,  policies  for 
service  consumers,  and  policies  for  infrastructure  providers,  because  each 
must  respond  in  predefined  ways  during  a  release. 

Implementation 

Mechanisms 

Implementation  mechanisms  are  suggested  approaches  to  implementing 
policies.  For  example,  implementing  a  policy  for  a  trusted  registry  may  in¬ 
volve  mechanisms  such  as  digital  signatures  for  interfaces  and  the  restric¬ 
tion  of  access  to  the  registry  to  select,  trusted  parties.  There  may  be  multiple 
mechanisms  required  to  implement  a  single  policy. 

Risks  and  Mitigations 

Multiple  risks  are  potentially  associated  with  each  policy  and  mechanism, 
and  multiple  mitigations  may  be  associated  with  risks.  Mitigations  may  be 
assigned  to  one  or  more  perspectives  and  may  ultimately  lead  to  additional 
tasks  or  policies. 
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Scenario  Element 

Description 

Implications 

Implications  relate  the  work  of  the  individual  groups  back  to  SOA  govern¬ 
ance  within  the  larger  organization.  Implications  of  policies,  implementation 
mechanisms,  and  associated  risks  may  potentially  affect  the  SOA  govern¬ 
ance  framework,  the  CoE,  best  practices,  tool  support,  or  any  other  aspect 
of  governance. 

Exceptions 

Exceptions  are  situations  where  proposed  policies  are  inappropriate  or 
where  alternate  policies  are  needed.  Exceptions  are  rarely  considered  when 
developing  SOA  governance  strategy,  but  almost  all  attempts  to  implement 
SOA  governance  will  be  faced  with  exceptions. 

Table  2  maps  each  element  of  a  scenario  to  the  activity  in  which  it  is  identified,  created,  or  up¬ 
dated.  (Note  that  no  scenario  element  is  identified,  created,  or  updated  in  the  create  affinity 
groups  activity.) 

Table  2:  Scenario  Elements  Mapped  to  Activities 


Activity 

Scenario  Element 

Establish 

context 

Develop 

classification 

schemes 

Create  affinity 

groups 

Create 

scenarios 

Consolidate 

scenarios  and 

create  policies 

Customize 

policies 

Concern 

Identify 

Scenario  Description 

Create 

Governance  Drivers 

Identify 

Scenario  Categories 

Create 

Update 

Perspectives 

Identify 

Update 

Policies 

Create 

Update 

Implementation  Mechanisms 

Suggest 

Suggest 

Suggest 

Risks  and  Mitigations 

Identify 

Update 

Update 

Implications 

Identify 

Identify 

Identify 

Exceptions 

Identify 

Identify 

Identify 

A  scenario  defined  using  the  template  is  shown  in  Table  3.  The  scenario  is  on  avoiding  services 
with  little  or  no  potential  for  use. 

Table  3:  Scenario  Example  Using  Template 


Scenario  Element 

Description 

Concern 

Departments  within  the  organization  start  to  deploy  services  and  there  is  no 
control  or  centralized  knowledge  of  deployed  services. 

Scenario  Description 

A  service  provider  that  tries  to  expose  a  service  that  corresponds  to  capabil¬ 
ity  with  limited  or  no  use  is  prevented  from  doing  so. 

Governance  Drivers 

Organization-wide  reuse  of  services  to  reduce  development  costs. 

Scenario  Category 

Service  Planning  Phase,  Service  Deployment  Phase 

Perspectives 

Service  provider,  infrastructure  provider  (infrastructure  provider  may  be  in¬ 
volved  if  part  of  the  verification  process  occurs  inside  the  infrastructure). 

Policies 

•  Before  starting  development,  any  service  provider  needs  to  prove  the 
business  need  for  the  service  and  that  the  service  is  not  redundant  with 
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Scenario  Element 

Description 

existing  services. 

•  All  available  services  have  to  be  published  in  the  centrally  accessible 
service  repository. 

Implementation 

Mechanisms 

•  Service  providers,  before  starting  service  development,  must  fill  out  a 
form  in  which  they  describe  the  capability  provided,  related  services  al¬ 
ready  available  in  the  registry,  and  business  processes  that  will  use  the 
service.  This  form  is  validated  by  business  process  owners. 

•  Services  providers  must  check  in  their  services  to  a  centrally  accessible 
registry. 

Risks  and  Mitigations 

Risk:  Service  providers  and  service  consumers  override  the  central  registry. 
Mitigation:  Create  an  audit  process  that  periodically  monitors  the 
service  usage  and  checks  for  non-registered  services. 

Risk:  The  service  metadata  does  not  provide  enough  information  about  the 
service  to  make  a  decision  on  redundancy. 

Mitigation:  Service  providers  can  provide  examples  of  service  us¬ 
age  and  the  business  process  where  the  service  is  being  used. 

The  service  consumers  should  also  update  the  metadata  based 
on  feedback  from  service  consumers. 

Implications 

All  groups  and  the  SOA  CoE  have  to  agree  on  a  tool  (e.g.,  registry)  and  the 
processes  that  should  be  suggested  in  the  implementation  mechanisms. 

Exceptions 

None 

3.6  Activity  5:  Consoiidate  Scenarios 

The  goal  of  consolidation  is  to  reconcile  and  merge  the  work  of  the  various  groups  in  order  to 
identify  SOA  governance  policies  for  the  organization.  This  process  is  carried  out  by  the  central 
authority  responsible  for  overall  SOA  governance  (e.g.,  the  SOA  CoE)  in  conjunction  with  repre¬ 
sentatives  from  the  various  affinity  groups.  Several  cases  may  arise  during  consolidation  of  sce¬ 
narios  generated  by  different  groups: 

1 .  A  scenario  is  consistently  included  by  multiple  groups  (i.e.,  multiple  groups  recognize  a 
similar  problem  and  address  it  in  similar  ways).  In  this  case,  the  goal  is  to  merge  the  sce¬ 
narios  and  establish  a  unified  policy  that  addresses  the  concerns  of  most  of  the  groups. 

2.  A  scenario  is  in  conflict  with  another  scenario.  In  this  case,  various  groups  have  differ¬ 
ent  understandings  or  prioritizations  of  SOA  governance  drivers.  It  is  important  to  under¬ 
stand  whether  the  conflict  is  at  the  level  of  implementation  or  the  business  goal.  Conflicts 
affecting  the  implementation  can  be  resolved  by  recommending  a  policy  and  an  appropri¬ 
ate  implementation  mechanism.  However,  if  the  business  goals  related  to  each  policy  are 
in  conflict,  the  scenarios  should  be  treated  separately. 

3.  A  scenario  is  unique.  In  this  case,  the  need  is  to  ensure  that  the  scenario  is  appropriately 
addressed  by  SOA  governance  policy. 

4.  Several  scenarios  across  groups  appear  to  be  similar,  although  they  are  actually  dif¬ 
ferent.  In  this  case,  the  scenarios  should  be  further  refined  to  differentiate  between  them. 

5.  Elements  of  a  scenario  from  one  group  are  in  conflict  with  one  or  more  scenarios 
from  other  groups.  For  example,  the  details  of  various  scenarios  may  suggest  conflicting 
policies  or  mechanisms  to  address  the  same  situation.  In  this  case,  the  need  is  to  reconcile 
the  work  of  the  groups  on  a  case-by-case  basis.  For  example,  two  groups  may  identify 
identical  scenarios  that  require  some  certification  of  services  prior  to  deployment.  One 
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group  advocates  central  certification  while  the  other  argues  for  local  certification.  The 
team  must  use  its  judgment  and  experience  to  select  a  solution  (e.g.,  central  certification, 
local  certification,  or  a  “third  way”).  A  different  approach  may  be  necessary  when  differ¬ 
ing  mechanisms  reflect  real  differences  in  context  or  SOA  governance  needs  across 
groups.  In  this  case,  the  organization  may  support  different  certification  strategies  for  dif¬ 
ferent  contexts. 

The  result  of  these  activities  is  a  single  set  of  consistent,  implementable  policies  across  the  vari¬ 
ous  groups  that  have  been  fully  validated  against  governance  drivers. 

3.7  Activity  6:  Customize  Policies  to  Fit  SOA  Governance  Framework 

The  primary  goal  of  the  customization  activity  is  to  fold  the  findings  of  the  various  teams,  now 
reflected  in  a  single  set  of  implementable  policies  and  other  elements,  back  into  the  organization- 
wide  SOA  governance  approach.  Customizing  policies  requires  the  consolidation  team  to  analyze 
whether  the  consolidated  scenarios  and  policies  are  consistent  with  the  selected  SOA  governance 
framework.  Several  interesting  cases  may  occur: 

1 .  Where  the  policies  do  not  provide  complete  coverage  of  the  framework,  a  decision  must  be 
made  whether  policies  should  be  added  or  are  not  needed  because  the  missing  coverage 
represents  areas  that  are  unnecessary  for  the  organization. 

2.  Where  policies  have  been  developed  that  do  not  map  to  the  framework,  the  framework 
may  need  to  be  extended.  This  need  may  arise  when  the  organization  has  specific  SOA  re¬ 
quirements  that  are  not  addressed  by  the  selected  SOA  governance  framework.  One  possi¬ 
ble  solution  is  to  look  at  other  frameworks  which  may  provide  elements  missing  from  the 
selected  framework. 

3.  Where  policies  are  inconsistent  with  the  framework,  either  the  polieies  or  the  framework 
needs  to  be  modified. 

A  seeondary  goal  of  the  eustomization  aetivity  is  to  identify  how  the  polieies  ean  be  implemented 
and  supported  aeross  the  organization.  The  information  eaptured  in  the  seenario  template  (see 
Table  1  on  page  13)  related  to  poliey  and  poliey  implementation  is  a  valuable  starting  point  for 
developing  the  organization’s  overall  SOA  govemanee  strategy. 

3.8  Evolve  and  Iterate 

It  is  unlikely  that  all  the  neeessary  polieies  required  for  SOA  govemanee  ean  be  established  in  a 
single  iteration  of  the  proeess  for  these  reasons: 

•  The  SOA  effort  in  an  organization  matures  and  ereates  govemanee  needs  in  new  areas. 

•  There  are  ehanges  in  teehnology. 

•  Business  goals  and  needs  ehange. 

The  organization  ean  aeeommodate  these  areas  of  ehange  by  periodieally  iterating  through  the 
proeess  to  identify  new  seenarios  and  the  eorresponding  SOA  govemanee  polieies  and  implemen¬ 
tation  meehanisms  to  support  them. 
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4  Conclusions 


Vendor  and  other  existing  SO  A  govemanee  frameworks  are  a  useful  starting  point  for  an  organi¬ 
zation  adopting  SOA.  However,  mandating  an  existing  framework  without  eonsidering  the  unique 
needs  of  the  organization  may  result  in  ineffieieneies,  overkill,  or,  even  worse,  eomplete  failure. 

Rather  than  by  fiat,  adoption  of  an  SOA  govemanee  framework  should  start  with  an  analysis  of 
organizational  needs  for  SOA  govemanee.  We  believe  that  the  seenario-based  teehnique  deseribed 
in  this  report  provides  a  meehanism  that  is  vendor  neutral,  eompatible  with  existing  SOA  govem¬ 
anee  frameworks,  simple,  and  easily  sealable.  The  teehnique  ean  be  used  in  the  early  phases  of 
SOA  adoption  to  lay  the  foundation  for  organization-speeifie  SOA  govemanee  and  ean  also  pro¬ 
vide  insight  into  a  sequeneing  of  polieies  based  on  aetual  needs.  The  teehnique  ean  also  be  used  to 
eapture  the  inevitably  ehanging  needs  for  govemanee  as  SOA  is  deployed.  Where  needs  are 
ehanging,  groups  ean  be  asked  to  eonsider  modifieations  to  existing  seenarios  and  to  generate  new 
seenarios  that  eapture  their  improved  and  ehanging  understanding.  These  ehanges  ean  then  be 
related  baek  to  the  existing  SOA  govemanee  framework. 
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Appendix  Examples  of  SOA  Governance  Frameworks 


This  appendix  is  a  list  in  alphabetical  order  of  some  of  the  SOA  governance  frameworks  that  were 
studied  for  the  creation  our  approach.  The  list  is  included  simply  to  show  examples  of  existing 
frameworks.  The  SEI  does  not  endorse  the  products  or  services  listed  below. 

AgilePath’s  SOA  Governance  Model 

According  to  AgilePath,  “SOA  governance  is  the  definition,  implementation  and  ongoing  execu¬ 
tion  of  an  SOA  stakeholder  decision  model  and  accountability  framework  that  ensures  an  organi¬ 
zation  is  pursuing  an  appropriate  SOA  strategy,  aligned  with  IT  and  business  goals,  and  is  execut¬ 
ing  that  strategy  in  accordance  with  guidelines  and  constraints  defined  by  a  body  of  SOA 
principles  and  policies.”  The  AgilePath  four-tier  governance  model  is  represented  in  Figure  4  [8]. 
This  model  is  tied  to  an  integrated  policy  enforcement  model  and  to  the  concept  of  governance 
performance  management.  Additional  information  can  be  found  at  http://www.agile-path.com. 

_ Enterprise/Strategic  IT  Governance _ 

rr/SOA  Strategic  Planning.  Funding  &  Budgeting,  Business  & 

Technology  Alignment.  Enterprise  Portfolio  Mgt.,  Enterprise 
Architecture,  Tech  Acquisition.  Reqts  &  Demand  Mgt.  PMO 

_ SOA  Operating  Model  Governance _ 

SOA  Opportunity  Managenoent  Service  Portfolio  ManageiT>ent. 

Service  Realization  and  Utilization,  Service  Promotion/Demotion, 

Legacy  Asset  Retirement.  SOA  Management  and  Process  Reviews 

SPEC  /  Services  Lifecycle  Governance 

Service  ID,  Modeling,  Design  &  Development,  QATTesting.  Publishing, 

Discovery,  Consumption,  Composition,  Orchestration,  Integration 
Testing,  Operations.  Maintenance,  Deprecation,  Retirement 


Governance  Enabling  Technology 

Design-time,  Publishing/Discovery,  Runtime 

Repositories,  Registries,  Intermediaries,  Policy  Engines,  Distributed 
Pol  icy  Enf  orcem  ent  Poi  nts 

I 


Figure  4:  AgilePath’s  Governance  Model 
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CBDi  SAE  SOA  Governance  Framework 


According  to  CBDi,  “SOA  governance  is  the  part  of  IT  governance  that  refers  to  the  organiza¬ 
tional  struetures,  polieies,  and  proeesses  that  ensure  that  an  organization's  SOA  efforts  sustain  and 
extend  the  organization's  business  and  IT  strategies,  and  aehieve  the  desired  outeomes.”  The 
CBDi  governanee  model  is  represented  in  Figure  5  as  a  set  of  different  views  that  address  the 
how,  what,  who,  and  when  aspeets  of  SOA  governanee  [9].  Additional  information  ean  be  found 
at  http://www.ebdiforum.eom. 


Organizational  View:  The  organizational 

sinictures,  roles  and  responsiMibes  necessary  WHO 

for  SOA  Governance 


Process  View;  The 
processes  lhal  need  lo 
be  followed  lo  establish 
govenuwice.and  set  and 
monitor  policies 


HOW 


Infrastructure  View:  The  technical  mfrastiucture 
available  to  support  SOA  Governance 


Maturity  View:  The 
governance  required  at 
each  level  of  SOA  Maturity 

WHEN 


Figure  5:  CBDi-SAE  SOA  Governance  Framework 
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IBM  SOA  Governance  and  Management  Method 

According  to  IBM,  “SOA  governance  is  an  extension  of  IT  governance  specifically  focused  on 
the  life  cycle  of  services,  metadata  and  composite  applications  in  an  organization’s  service- 
oriented  architecture.”  Consistent  with  this  definition,  the  IBM  SOA  governance  model  is  based 
on  a  life  cycle  for  SOA  governance,  in  which  each  phase  has  defined  steps  and  deliverables,  as 
shown  in  Figure  6  [4],  Some  of  the  speeifie  elements  that  are  eovered  in  the  framework  are  een- 
tered  on  the  life  eyele  for  serviees,  from  identifieation  to  deployment  to  eonsumption.  Additional 
information  ean  be  found  at  http://www-01.ibm.eom/software/solutions/soa/gov/. 


Plan  Define  Enable  Measure 

Detefnime  the  Define  the  SOA  Implement  the  SOA  Refine  the  SOA 

Governance  Focus  Governance  Model  Governance  Model  Governance  Model 


Understand  current 
governance  structures 

Create  fT  governance 
baseline 

Define  scope  of 
governance 

Conduct  change 
readiness  survey 


Dehne  and  refine 
governance  processes 

Define  organizational 
change 


Define  ff  changes  in 
SOA  development 


Implement  the 
transition  plan 

Initiate  SOA  Org 
Changes 

Launch  the  SOA  Center 
of  Excellence 

Implement 

infrastructure  for  SOA 


Measure  effectiveness 
governance  processes 

Measure  effecbvertess 
of  organization  change 

Review  and  refine 
operational  environment 


Commious  SOA  Gov&mmce  Ptaeess  BSeasmnrmttt  &  tmprovcmoBt 


Define  the  fcop*  of 
goYtmtnoe:  bocincM, 
developtnent  governance  or 
tenhoe  menegemeot  or  eM  of 
theebove 


Define  new  governance 
proceote*  for  tervioee  and 
define  SCM  90verTuoce 
mechaniemt  auch  at  the  SOA 
Center  of  Excellence 


Begin  implementation  of  the 
SOA  Center  of  Exoedenoe, 
SkMs  Bnablement, 
Organaabonal  Change. 
Infraatruclure  Change,  etc 


Monitor  compoaite 
application  performance 
andadfust.  Monitor 
effectivene**  of  governance 
crMn9M 


Figure  6:  IBM  SOA  Governance  and  Management  Method 
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Information  Technology  Infrastructure  Library  (ITIL) 

ITIL  is  a  framework  developed  by  the  OGC  (Offiee  of  Govemanee  Commeree)  on  behalf  of  the 
British  government.  ITIL  is  eomposed  of  best  praetiees  and  polieies  for  IT  serviee  management. 
ITIL  v3  is  divided  into  Serviee  Strategies,  Serviee  Design,  Serviee  Transition,  Serviee  Operation, 
and  Continual  Serviee  Improvement,  as  shown  in  Figure  7  [19].  Even  though  the  seope  of  IT  ser- 
viees  is  beyond  serviees  in  the  SOA  eontext,  mueh  of  the  guidanee  in  ITIL  has  applieation  to 
SOA  serviee  development,  deployment,  and  management.  Additional  information  ean  be  found  at 
http://www.oge.gov.uk/,  http://www.itil.org,  and  http://www.itil-offieialsite.eom/. 
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Figure  7.'  ITIL  Core  Framework 
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Oracle  SOA  Governance  Model 


According  to  Oracle,  “SOA  Governance  can  be  defined  as  the  interaction  between  policies  (what), 
decision-makers  (who),  and  processes  (how)  in  order  to  ensure  SOA  success.”  The  Oracle  SOA 
governance  model  includes  a  set  of  best  praetiees  and  a  six-step  proeess  to  define  SOA  govem- 
anee.  It  is  organized  around  key  leverage  points  for  SOA  govemanee  polieies,  as  shown  in  Figure 
8  [5].  Additional  information  ean  be  found  at  http://www.oraele.eom/teehnologies/soa/soa- 
govemanee.html. 
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Figure  8:  Oracle  SOA  Governance  Model  (Key  Leverage  Points  for  Policies) 
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SOA  Software  SOA  Governance  Model 


According  to  SOA  Software,  “SOA  Governance  is  about  making  sure  that  the  enterprise  builds 
the  right  things,  builds  them  right,  and  makes  sure  that  what  it  has  built  is  behaving  right.”  SOA 
Software’s  SOA  governance  model  is  organized  around  an  integrated  SOA  governance  solution 
that  is  automated  by  its  product  portfolio.  At  a  high  level,  the  model  is  organized  around  planning, 
development,  operational,  and  poliey  govemanee,  as  presented  in  Figure  9  [6].  It  ineludes  a  set  of 
best  praetiees  and  use  eases  to  aid  in  SOA  govemanee  implementation.  Additional  information 
ean  be  found  at  http://www.soa.eom/. 
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Figure  9:  SOA  Software  Integrated  Governance  Model 
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Software  AG  SOA  Governance  Model 


According  to  Software  AG,  “SOA  governance  is  [a]  subset  of  IT  governance.  It  establishes  poli¬ 
cies,  controls,  and  enforcement  mechanisms  required  for  successful  SOA  adoption  by  giving  IT 
visibility  and  control  over  their  SOA  development  and  deployment.”  The  model  is  based  on  ser¬ 
vice-level  life  eyele  govemanee  that  is  supported  by  their  produet  suite  [7].  Additional  informa¬ 
tion  ean  be  found  at  http://www.sofitwareag.eom/Corporate/produets/wm/soa_govemanee/ 
defiault.asp. 


24  I  CMU/SEI-2008-TN-019 


References 


URLs  are  valid  as  of  the  publication  date  of  this  document. 


[1]  P.  Malinvemo,  “Service-Oriented  Architecture  Craves  Governance,”  Gartner  Group,  Re¬ 
search  Report,  2006. 

[2]  “InfoWorld  Research  Report:  Service  Oriented  Architecture  (SOA),”  2007.  [Online]. 
Available:  http://www.s2.com.br/s2arquivos/403/multimidia/l 97Multi.pdf.  [Accessed: 

May  1,2009]. 

[3]  B.  Woolf,  “Introduction  to  SOA  Governance,”  June  13,  2006.  [Online].  Available: 
http://www.ibm.com/developerworks/library/ar-servgov/index.html.  [Accessed:  May  1, 
2009]. 

[4]  W.  A.  Brown,  G.  Moore,  and  W.  Tegan,  “SOA  Governance  -  IBM’s  Approach,”  2006. 
[Online].  Available:  ftp://ftp.software.ibm.com/software/soa/pdf/SOA_Gov_Process_ 
Overview.pdf.  [Accessed:  May  1,  2009]. 

[5]  M.  Afshar,  “SOA  Governance:  Framework  and  Best  Practices,  Version  1.1,”  Oracle,  May 
2007.  [Online].  Available:  http://www.oracle.com/technologies/soa/docs/oracle-soa- 
governance-best-practices.pdf  [Accessed:  May  1,  2009]. 

[6]  “SOA  Software  White  Paper:  Integrated  SOA  Governance,”  2007.  [Online].  Available: 
http://www.soa.com/index.php/user_account/download.php?r=Resource_Center/White_Pa 
pers/SOASoft_Int_SOA_Govemance.pdf  [Accessed:  May  1,2009]. 

[7]  F.  Castaldini,  “Software  AG  White  Paper:  SOA  Governance  and  CentraSite:  Ensuring 
SOA  Success  with  Effective,  Automated  Control  Throughout  the  Lifecycle,”  2008.  [On¬ 
line].  Available:  http://www.softwareag.com/Corporate/Images/SAG_SOAGov_  Centra- 
Site_WP_Apr08-web[l Ltcml6-40610.pdf.  [Accessed;  May  1,  2009]. 

[8]  E.  Marks,  SOA  Governance:  Evolving  Governance  in  the  Services-Driven  Enterprise.  New 
York:  John  Wiley  &  Sons,  2008. 

[9]  P.  Allen,  “SOA  Governance:  Challenge  or  Opportunity?”  SOA  Best  Practice  Report,  CBDI 
Forum,  2008.  [Online].  Available:  http://www.cbdiforum.com/report_  sum- 
mary.php3?page=/secure/interact/2008-04/challenge_opportunity.php&area=silver.  [Ac¬ 
cessed:  May  1,  2009]. 

[10]  S.  Taylor  and  M.  N.  Iqbal,  ITIL  Service  Strategy.  London:  The  Stationary  Office,  2007. 

[11]  A.  Arsanjani  and  K.  Holley,  “Increase  flexibility  with  the  Service  Integration  Maturity 
Model  (SIMM),”  Sept.  30,  2005.  [Online].  Available:  http://www- 
128.ibm.com/developerworks/webservices/library/ws-soa-simm/  [Accessed:  may  1,  2009]. 


25  I  CMU/SEI-2008-TN-019 


[12]  D.  Sprott,  “The  SOA  Maturity  Model — ^Part  II,”  SOA  Best  Praetiee  Report,  CBDi  Forum, 
Mareh  22,  2006.  [Online].  Available:  http://www.ebdiforum.eom/report 
_summary.php3?page=/seeure/interaet/2006- 

03/The_SOA_Maturity_Model_Part2.php&area=silver.  [Aeeessed:  May  1,  2009] 

[13]  F.  I.  Kenney,  D.  C.  Plummer,  and  K.  Harris,  K.,  “No  'Leader'  Exists  in  SOA  Governanee  ... 
At  Least  Not  Yet,”  Gartner  Group,  Researeh  Report,  2007. 

[14]  L.  The.  “SOA  Governanee  -  'Not  Mueh'  Sueeess,  Panelists  Say,”  Applieation  Development 
Trends,  Feb.  14,  2008.  [Online].  Available:  http://www.adtmag.eom/ 
artiele.aspx?id=22055.  [Aeeessed:  May  1,  2009]. 

[15]  A.  G.  Suteliffe,  N.  A.  M.  Maiden,  S.  Minoeha,  and  D.  Manuel,  “Supporting  seenario-based 
requirements  engineering,”  IEEE  Transaetions  on  Software  Engineering,  vol.24,  no.  12, 
pp.  1072-1088  (Dee.  1998). 

[16]  R.  Kazman,  M.  Klein,  and  P.  Clements,  “ATAM:  Method  for  Arehiteeture  Evaluation,” 
Software  Engineering  Institute,  Carnegie  Mellon  University,  CMU/SEI-2000-TR-004, 
2000. 

[17]  “SOA  Governanee  User  Survey:  Best  Praetiees  for  SOA  Governanee  User  Survey,”  Soft¬ 
ware  AG,  2008.  [Online].  Available:  http://www.softwareag.eom/Corporate/res/ 
SOAGovemaneeSurvey.asp.  [Aeeessed:  May  1,  2009]. 

[18]  “Inereasing  the  Effeetiveness  and  Effieieney  of  SOA  Through  Governanee,  2008  SOA  Go¬ 
vernanee  Survey  Report,”  Oraele,  2008.  [Online].  Available:  http://www.ebizq.net/ 
white_papers/10075.html.  [Aeeessed:  May  1,  2009]. 

[19]  “ITIL  Knowledge,”  ITIL.org,  2009.  [Online].  Available:  http://www.itil.org/en/.  [Ae¬ 
eessed:  May  1,  2009]. 


26  I  CMU/SEI-2008-TN-019 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  search¬ 
ing  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regard¬ 
ing  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters 
Services,  Directorate  for  information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,  and  to  the  Office  of 
Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503. 

1.  AGENCYUSEONLY 

(Leave  Blank) 

2.  REPORT  DATE 

June  2009 

3.  REPORT  TYPE  AND  DATES 

COVERED 

Final 

4.  TITIE  AND  SUBTITLE 

A  Scenario-Based  Technique  for  Developing  SOA  Technical  Governance 

5.  FUNDING  NUIVBERS 

FA8721-05-C-0003 

6.  AUTHCIR(S) 

Soumya  SImanta,  Ed  Morris,  Grace  A.  Lewis,  Shram  Balasubramanlam,  and  Dennis  B.  Smith 

7 .  PERFORMNG  ORGANIZATION  NAIVE(S)  AND  ADDRESS(ES) 

Software  Engineering  Institute 

Carnegie  Mellon  University 

Pittsburgh,  PA  15213 

8 .  PERFORMNG  ORGANIZATION 

REPORT  NUIVBER 

CMU/SEI-2009-TN-009 

9.  SPONSORING/MONITORING  AGENCY  NAIVE(S)  AND  ADDRESS(ES) 

HQ  ESC/XPK 

5  Eglin  Street 

HanscomAFB,  MA  01731-21 16 

10.  SPONSORING/MONITORING 

AGENCY  REPORT  NUIVBER 

11.  SUPPLENENTARY  NOTES 

12a  DISTRIBUnOfVAVAILABIUTYSTATEWENrr 

Unclassifled/Unllmited,  DTIC,  NTIS 

12b  DISTRIBUTION  code 

13.  ABSTI^CT  (MAXIMUM  200  VVC^ 

A  well-known  problem  within  the  service-oriented  architecture  (SOA)  community  Is  the  need  to  establish  effective  SOA  governance  pro¬ 
cedures  to  enable  an  organizatlon-wlde  SOA  Initiative.  A  number  of  organizations  and  vendors  address  this  problem  through  SOA  gov¬ 
ernance  frameworks  that  provide  models,  procedures,  and  tools  for  SOA  governance.  Many  of  these  SOA  frameworks  are  general  pur¬ 
pose  because  they  are  Intended  to  be  useful  for  a  diverse  customer  base.  However,  while  designed  for  a  wide  customer  base,  vendor 
SOA  frameworks  are  narrowly  focused  to  work  with  the  specific  tools  of  the  vendor.  A  critical  problem  for  an  organization  when  Imple¬ 
menting  SOA  governance  Is  to  customize  vendors’  offerings  to  Its  specific  technological  and  management  context.  In  this  technical  note, 
a  lightweight  and  extensible  technique  Is  proposed,  one  that  employs  scenarios  to  tailor  existing  SOA  governance  frameworks  to  the 
specific  needs  of  an  organization. 

14.  SUBJECTTEFtMS  15.  NUIVBER OF  PAGES 

SOA,  SOA  governance,  scenario-based  technique,  service  management,  policy,  best  prac-  37 

tices,  risks 

16.  PRICECXCIE 

17.  SECXIFaTYCLASSIHCATlONOF  18.  SECUFtnYCLASSIHCATlON  19.  SECXIFaTYCLASSIHCATlON  20.  UMTATIONOF 

REPORT  OFTHISPAGE  OF  ABSTRACT  ABSTRACT 

Unclassified  Unclassified  Unclassified  UL 


NSN  7540-01-280-5500 


standard  Form  298  (Rev.  2-89)  Prescribed  by  ANSI  Std.  Z39-18 
298-102 


